Systems and methods for determining estimated lead times

ABSTRACT

Embodiments of the invention may provide systems and methods for determining estimated lead times based on delivery history information to a same or similar geographical area. According to one example embodiment, a method is provided. The method can include identifying a payee and determining that the payee is associated with a geographical area for mailpiece delivery. The method can further include identifying multiple delivery methods for mailpiece delivery to the geographical area, wherein each of delivery methods is associated with (a) a distribution center, (b) a delivery agent, and (c) an estimated lead time determined at least in part by analyzing the delivery history information associated with multiple mailpieces mailed from the respective distribution center to the geographical area via the respective delivery agent. The method can further include selecting one of the delivery methods for mailpiece delivery to the payee and associating the selected delivery method with the payee.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation application of U.S. application Ser.No. 13/554,959, filed Jul. 20, 2012, which is a continuation of U.S.application Ser. No. 12/481,353, filed Jun. 9, 2009, now U.S. Pat. No.8,244,646, issued Aug. 14, 2012.

FIELD OF THE INVENTION

Aspects of the invention relate generally to bill payment, and moreparticularly to systems and methods for determining estimated lead timesfor delivering paper instruments.

BACKGROUND OF THE INVENTION

Financial institutions and payees often provide online services to theircustomers, many of which may be performed at least in part via paymentservice providers. In one example, payment service providers cancomplete payment transactions to payees on behalf of a payor, which mayalso be a customer (also referred to as a “subscriber”) of the paymentservice provider. A payment service provider typically receives apayment request and then will typically either print and mail paymentsto the payee or process the payments electronically.

Payors may manage the timing of making payments, such as to retaincontrol of funds as long as possible, to avoid late payments, and tocoordinate with available funds or cash flow. Similarly, payment serviceproviders also desire to control the timing of issuing payments onbehalf of their customers and/or the delivery methods used.

BRIEF DESCRIPTION OF THE DRAWINGS

Reference will now be made to the accompanying drawings, which are notnecessarily drawn to scale, and wherein:

FIG. 1 illustrates an overview of an example system for estimating leadtimes and selecting delivery methods, according to an example embodimentof the invention.

FIG. 2 illustrates a block diagram of an example lead time estimationprocess, according to an example embodiment of the invention.

FIG. 3 illustrates a flow diagram of an example process for determiningestimated lead times, according to an example embodiment of theinvention.

FIGS. 4A-4B illustrate a flow diagram of an example process fordetermining estimated lead times and presenting or associating estimatedlead times with payees or other recipients, according to an exampleembodiment of the invention.

FIGS. 5A-5C illustrate example user interfaces for presenting estimatedlead time information to a subscriber, according to an exampleembodiment of the invention.

FIG. 6 illustrates a block diagram of an example delivery methodselection process, according to an example embodiment of the invention.

FIG. 7 illustrates a flow diagram of an example process for selectingdelivery methods, according to an example embodiment of the invention.

DETAILED DESCRIPTION

The invention will now be described more fully hereinafter withreference to the accompanying drawings, in which example embodiments ofthe invention are shown. This invention may, however, be embodied inmany different forms and should not be construed as limited to theexample embodiments set forth herein; rather, these example embodimentsare provided so that this disclosure will be thorough and complete, andwill fully convey the scope of the invention to those of ordinary skillin the art. Like numbers refer to like elements throughout.

Embodiments of the invention may provide for estimating payment leadtimes for paper instruments for a payee based on delivery historyinformation associated with the delivery of mailpieces between one ormore distribution centers and a same or similar geographical area as thepayee's geographical area (e.g., zip code). The delivery historyinformation can include at least a mail date and receipt date, or otherdata indicating when the receipt date may have been (e.g., checkclearance date), which allows a delivery time for each of the mailpiecesrepresented in the delivery history information to be calculated.Accordingly, by analyzing delivery times for prior mailings to thepayee's geographical area, an estimated lead time for mailing a paperinstrument or other mailpiece to the analyzed geographical area can bedetermined. Moreover, by focusing on the geographical area to determineestimated lead times, delivery history information can be consideredfrom multiple payees or other recipients, and the estimated lead timedetermined can be representative of lead times for delivering mailpiecesto multiple payees or to other recipients in that same geographicalarea.

According to various embodiments, providing more accurate estimates forpayment lead times can permit a subscriber to submit a payment requestcloser to the delivery date, thus allowing the subscriber to retain agreater balance for a longer duration of time and/or benefit fromincreased interest generation. Having accurate lead times available alsopermits subscribers to time their payments based on cash flow, availablebalances, or personal preferences, for example. In addition,unnecessarily early deliveries of paper instrument-based payments can beavoided by providing a more accurate lead time estimate, allowing apayment service provider (also referred to interchangeably herein as a“service provider”) to better time the printing and delivery of paperinstrument payments, such as to maintain a higher balance and benefitfrom increased interest generation.

Delivery methods for delivering paper instruments can vary according tonumerous factors, including, but not limited to, the distributioncenters from which paper instruments are mailed, the delivery agentsused for delivery, the transportation means and/or priority servicesrequested, and the like. Each different delivery method may have adifferent lead time associated therewith. Therefore, according to oneembodiment, more accurate estimated lead times can permit a paymentservice provider to select the preferred delivery method for mailingpaper instrument payments. In addition to estimated lead times, othercharacteristics and factors associated with various available deliverymethods (e.g., cost, delivery agent preferences, distribution centerpreferences or availability, delivery timing, subscriber permissions,etc.) can be collected from delivery history information associated withmailpieces delivered to the same or similar geographical areas. Theseadditional delivery method characteristics can also be considered by aservice provider when selecting a delivery method for delivery ofmailpieces.

As used herein, the term “subscriber” generally refers to an individual,business, or any other entity that uses electronic bill presentment andpayment applications, such as may be provided by one or more serviceproviders. Also as used herein, the term “payor” generally refers to asubscriber requesting or otherwise providing payment to anotherbusiness, individual, or other entity. Thus, the term “payee” generallyrefers to a business, individual, or other entity receiving payment,such as may be received via an electronic payment application providedby one or more service providers. The term “service provider” generallyrefers to an entity operable to process payments on behalf of a payee orsubscriber. A service provider may process payments on behalf ofindividuals, organizations, or any other entities. Payment requests canbe received by a service provider directly from a subscriber, or fromany other entity on behalf of a subscriber. Though, according to someembodiments, a service provider is not limited to a payment serviceprovider, and can generally refer to any entity facilitatingtransactions with other entities on behalf of its customers.

I. System Overview

FIG. 1 illustrates an example system 100 for estimating payment leadtimes and selecting delivery methods, according to an example embodimentof the invention. Although various computing devices and/or computersare illustrated in FIG. 1, it is appreciated that corresponding entitiesand/or individuals are associated with each of the computersillustrated. According to various embodiments, there may be: one or moreservice providers, each associated with one or more service providercomputers 110; one or more financial institutions (e.g., bank), eachassociated with one or more financial institution computers 120; one ormore delivery agents (e.g., postal carrier, shipping company, etc.),each associated with one or more delivery agent computers 130; one ormore subscribers (e.g., payee, bank, and/or service provider customers),each associated with one or more subscriber computers 140; and one ormore payees (e.g., billers, each associated with one or more payeecomputers 150. According to various embodiments, there may be any numberof each entity type, and each entity may be associated with multiplecomputers. For simplicity, the computers and/or entities may bereferenced in the singular, but it is appreciated that the samedescription applies to embodiments including multiple computers and/orentities. Similarly, for each of the computers described herein, it isappreciated that there may be any number of the various components andfeatures of each of the computers (e.g., multiple processors, memoryelements, application modules, etc.), but each may be referred to hereinin the singular for simplicity.

As shown in FIG. 1, a service provider computer 110, one or morefinancial institution computers 120, one or more delivery agentcomputers 130, one or more subscriber computers 140, and one or morepayee computers 150 may be in communication with each other via anetwork 160, which, as described below, can include one or more separateor shared private and/or public networks, including the Internet or apublicly switched telephone network. More specifically, according tovarious embodiments, the service provider computer(s) 110 can beoperable to receive check clearing information from one or more of thefinancial institution computers 120 or one or more of the payeecomputers 150 and/or mailpiece delivery status information from one ormore delivery agent computers 130. The service provider computer(s) 110is operable to analyze the check clearing information and/or themailpiece delivery status information to determine estimated lead timesfor delivering mailpieces to the same or similar geographical area. Theservice provider computer(s) 110 can also be operable to communicate toone or more subscriber computers 140 and/or one or more payee computers150 estimated lead times associated with payees and/or respectivepayments. According to various embodiments, estimated lead times can becommunicated to any other entity illustrated by FIG. 1 or not, such as aconsumer service provider for the subscriber that is operable to presentthe user interface or other features of the services to the subscriber(which may be a financial institution or other entity). The serviceprovider computer(s) 110 can also be operable to analyze variousavailable delivery methods and associated characteristics to select adelivery method from available delivery methods for delivery to a givengeographical area. Each of these components—the one or more serviceprovider computers 110, the one or more financial institution computers120, the one or more delivery agent computers 130, the one or moresubscriber computers 140, the one or more payee computers 150, and thenetwork 160—will now be discussed in further detail.

First, each of the one or more service provider computer(s) 110 may beany processor-driven device, such as, but not limited to, a servercomputer, a mainframe computer, one or more networked computers, adesktop computer, a personal computer, a laptop computer, a mobilecomputer, or any other processor-based device. In addition to having oneor more processors 116, the service provider computer 110 may furtherinclude one or more memory(s) 112, one or more input/output (“I/O”)interface(s) 118, and one or more network interface(s) 117. Thememory(s) 112 may be any computer-readable medium, coupled to theprocessor(s) 116, such as RAM, ROM, and/or a removable storage devicefor storing data files 115 and operable with one or more associateddatabase management systems (“DBMS”) to facilitate management of datafiles 115 and other data stored in the memory(s) 112 and/or stored inone or more separate database(s) 119 and associated hardware(illustrated collectively as a “database”). The memory(s) 112 may alsostore various program modules, such as an operating system (“OS”) 114,one or more lead time module(s) 111, one or more delivery methodmodule(s) 113, and any other computer software as may typically beexecuted by or otherwise included with a computer device (e.g., drivers,toolkits, middleware, application packages, file manager, browser,etc.). The OS 114 may be, but is not limited to, Microsoft Windows®,Apple OSX™, Unix, a mainframe computer operating system (e.g., IBM z/OS,MVS, OS/390 earlier, etc.), or a specially designed operating system.The lead time module(s) 111 may comprise computer-executable programinstructions or software for receiving, storing, extracting, managing,processing, and analyzing delivery history information to facilitateestimating payment lead times from given distribution centers or othersenders to given geographical areas (e.g., zip codes). The deliverymethod module(s) 113 may comprise computer-executable programinstructions or software for extracting lead time estimationinformation, such as may be determined by the lead time module 111, andadditional delivery characteristics, such as may be received by theservice provider computer 110, delivery agent computer(s) 130, and/orany other entity, for analyzing various delivery method options andselecting a delivery method from the available delivery methods.

Still referring to the service provider computer(s) 110, the I/Ointerface(s) 118 may facilitate communication between the processor 116and various I/O devices, such as a keyboard, mouse, printer, microphone,speaker, monitor, barcode readers/scanners, RFID readers, and the like.The network interface(s) 117 may take any of a number of forms, such as,but not limited to, a network interface card, a modem, a wirelessnetwork card, a cellular network card, and the like. Indeed, the serviceprovider computer 110 can receive delivery history information vianetwork interface(s) 117 and additionally transmit estimated lead timeinformation, perhaps, but not limited to, to a subscriber computer 140,via the network interface(s) 117. It will be appreciated that serviceprovider computer(s) 110 may be implemented as a particular machine,which may include a computer that is designed, customized, configured,or programmed to perform at least one or more functions of the lead timemodule 111 and/or the delivery method module 113, according to anexample embodiment of the invention.

Second, each of the one or more financial institution computer(s) 120may be any processor-driven device, such as, but not limited to, aserver computer, a mainframe computer, one or more networked computers,a desktop computer, a personal computer, a laptop computer, a mobilecomputer, or any other processor-based device. In addition to having oneor more processors 126, the financial institution computer(s) 120 mayfurther include one or more memory(s) 122, one or more input/output(“I/O”) interface(s) 128, and one or more network interface(s) 127. Thememory(s) 122 may be any computer-readable medium, coupled to theprocessor 126, such as RAM, ROM, and/or one or more removable storagedevice(s) for storing data files 125, operable with one or moreassociated database management systems (“DBMS”) to facilitate managementof data files 125 and other data stored in the memory 122 and/or storedin one or more separate database(s) 129 and associated hardware(illustrated collectively as a “database”). The memory(s) 122 may alsostore various program modules, such as an operating system (“OS”) 124,one or more financial institution application module(s) 123, and anyother computer software as may typically be executed by or otherwiseincluded with a computer device (e.g., drivers, toolkits, middleware,application packages, file manager, browser, etc.). The OS 124 may be,but is not limited to, Microsoft Windows®, Apple OSX™, Unix, a mainframecomputer operating system (e.g., IBM z/OS, MVS, OS/390 earlier, etc.),or a specially designed operating system. The financial institutionapplication module(s) 123 may comprise computer-executable programinstructions or software, including a dedicated program, to facilitateoperations of the financial institution with which it is associated. Inone example, the financial institution application module(s) 123 canprovide information to the service provider computer(s) 110 regardingthe date/time at which one or more checks cleared with the respectivefinancial institution.

Still referring to the financial institution computer(s) 120, the I/Ointerface(s) 128 may facilitate communication between the processor(s)126 and various I/O devices, such as a keyboard, mouse, printer,microphone, speaker, monitor, barcode readers/scanners, RFID readers,and the like. The network interface(s) 127 may take any of a number offorms, such as, but not limited to, a network interface card, a modem, awireless network card, a cellular network card, and the like. Indeed,the financial institution computer(s) 120 can transmit check clearanceinformation to any other entity computer, such as, but not limited to,the service provider computer(s) 110 via network interface(s) 127. Itwill be appreciated that the financial institution computer(s) 120 maybe implemented as a particular machine, which may include a computerthat is designed, customized, configured, or programmed to perform atleast one or more functions of the financial institution applicationmodule(s) 123, according to an example embodiment of the invention.

Third, each of the one or more delivery agent computer(s) 130 may be anyprocessor-driven device, such as, but not limited to, a server computer,a mainframe computer, one or more networked computers, a desktopcomputer, a personal computer, a laptop computer, a mobile computer, orany other processor-based device. In addition to having one or moreprocessor(s) 136, the delivery agent computer(s) 130 may further includeone or more memory(s) 132, one or more input/output (“I/O”) interface(s)138, and one or more network interface(s) 137. The memory(s) 132 may beany computer-readable medium, coupled to the processor(s) 136, such asRAM, ROM, and/or one or more removable storage device(s) for storingdata files 135 and operable with one or more associated databasemanagement systems (“DBMS”) to facilitate management of data files 135and other data stored in the memory 132 and/or stored in one or moreseparate database(s) 139 and associated hardware (illustratedcollectively as a “database”). The memory(s) 132 may also store variousprogram modules, such as an operating system (“OS”) 134, one or moredelivery agent application module(s) 133, and any other computersoftware as may typically be executed by or otherwise included with acomputer device (e.g., drivers, toolkits, middleware, applicationpackages, file manager, browser, etc.). The OS 134 may be, but is notlimited to, Microsoft Windows®, Apple OSX™ Unix, a mainframe computeroperating system (e.g., IBM z/OS, MVS, OS/390 earlier, etc.), or aspecially designed operating system. The delivery agent applicationmodule(s) 133 may comprise computer-executable program instructions orsoftware to facilitate the operations of the delivery agent. Forexample, the delivery agent application module(s) 133 can be operable totransmit delivery information to the service provider computer(s) 110for analysis to estimate payment lead times (in addition to, or insteadof, check clearance information transmitted from the financialinstitution computer(s) 120). The delivery agent application module 133can also be operable to transmit additional delivery characteristicsassociated with mailpiece deliveries to the service provider computer110 for analysis to select preferred delivery methods for variouscircumstances.

Still referring to the delivery agent computer(s) 130, the I/Ointerface(s) 138 may facilitate communication between the processor(s)136 and various I/O devices, such as a keyboard, mouse, printer,microphone, speaker, monitor, barcode readers/scanners, RFID readers,and the like. The network interface(s) 137 may take any of a number offorms, such as, but not limited to, a network interface card, a modem, awireless network card, a cellular network card, and the like. Indeed,the delivery agent computer(s) 130 can transmit mailpiece deliverystatus information and/or delivery method characteristics to the serviceprovider computer 110, or any other system, via network interface(s)137. It will be appreciated that delivery agent computer(s) 130 may beimplemented as a particular machine, which may include a computer thatis designed, customized, configured, or programmed to perform at leastone or more functions of the delivery agent application module(s) 133,according to an example embodiment of the invention.

Fourth, each of the one or more subscriber computer(s) 140 may be anyprocessor-driven device, such as, but not limited to, a server computer,a mainframe computer, one or more networked computers, a desktopcomputer, a personal computer, a laptop computer, a mobile computer, orany other processor-based device. In addition to having one or moreprocessor(s) 146, the subscriber computer(s) 140 may further include oneor more memory(s) 142, one or more input/output (“I/O”) interface(s)148, and one or more network interface(s) 147. The memory(s) 142 may beany computer-readable medium, coupled to the processor(s) 146, such asRAM, ROM, and/or a removable storage device for storing data files 145and operable with one or more associated database management systems(“DBMS”) to facilitate management of data files 145 and other datastored in the memory 142 and/or stored in one or more separatedatabase(s) 149 and associated hardware (illustrated collectively as a“database”). The memory(s) 142 may also store various program modules,such as an operating system (“OS”) 144, a subscriber application module143, and any other computer software as may typically be executed by orotherwise included with a computer device (e.g., drivers, toolkits,middleware, application packages, file manager, browser, etc.). The OS144 may be, but is not limited to, Microsoft Windows®, Apple OSX™, Unix,a mainframe computer operating system (e.g., IBM z/OS, MVS, OS/390earlier, etc.), or a specially designed operating system. The subscriberapplication module 143 may comprise computer-executable programinstructions or software for accessing electronic bill presentment andpayment applications, such as an online payment application hosted orotherwise provided by the service provider computer(s) 110, which can beaccessible over the network 160, such as via an Internet browser programrunning on the subscriber computer(s) 140.

Still referring to the subscriber computer(s) 140, the I/O interface(s)148 may facilitate communication between the processor(s) 146 andvarious I/O devices, such as a keyboard, mouse, printer, microphone,speaker, monitor, barcode readers/scanners, RFID readers, and the like.The network interface(s) 147 may take any of a number of forms, such as,but not limited to, a network interface card, a modem, a wirelessnetwork card, a cellular network card, and the like. Indeed, thesubscriber computer(s) 140 can access an electronic bill presentment andpayment application operated by the service provider computer(s) 110, orby any other entity, via network interface(s) 147. It will beappreciated that the subscriber computer 140 may be implemented as aparticular machine, which may include a computer that is designed,customized, configured, or programmed to perform at least one or morefunctions of the subscriber application module(s) 143, according to anexample embodiment of the invention.

Fifth, each of the one or more payee computer(s) 150 may be anyprocessor-driven device, such as, but not limited to, a server computer,a mainframe computer, one or more networked computers, a desktopcomputer, a personal computer, a laptop computer, a mobile computer, orany other processor-based device. In addition to having one or moreprocessor(s) 156, the payee computer(s) 150 may further include one ormore memory(s) 152, one or more input/output (“I/O”) interface(s) 158,and one or more network interface(s) 157. The memory(s) 152 may be anycomputer-readable medium, coupled to the processor(s) 156, such as RAM,ROM, and/or one or more removable storage device(s) for storing datafiles 155 and operable with one or more associated database managementsystems (“DBMS”) to facilitate management of data files 155 and otherdata stored in the memory(s) 152 and/or stored in one or more separatedatabase(s) 159 and associated hardware (illustrated collectively as a“database”). The memory(s) 152 may also store various program modules,such as an operating system (“OS”) 154, one or more payee applicationmodule(s) 153, and any other computer software as may typically beexecuted by or otherwise included with a computer device (e.g., drivers,toolkits, middleware, application packages, file manager, browser,etc.). The OS 154 may be, but is not limited to, Microsoft Windows®,Apple OSX™, Unix, a mainframe computer operating system (e.g., IBM z/OS,MVS, OS/390 earlier, etc.), or a specially designed operating system.The payee application module(s) 153 may comprise computer-executableprogram instructions or software to facilitate the operations of thepayee with which it is associated. According to one embodiment, thepayee application module(s) 153 can be operable to process payments,which may facilitate triggering the transmittal of check clearanceinformation to the service provider computer(s) 110 for analysis toestimate payment lead times for the respective payees' geographicalareas.

Still referring to the payee computer(s) 150, the I/O interface(s) 158may facilitate communication between the processor(s) 156 and variousI/O devices, such as a keyboard, mouse, printer, microphone, speaker,monitor, barcode readers/scanners, RFID readers, and the like. Thenetwork interface(s) 157 may take any of a number of forms, such as, butnot limited to, a network interface card, a modem, a wireless networkcard, a cellular network card, and the like. Indeed, the payeecomputer(s) 150 can receive payment information from the subscribercomputer 140, or any other system, such as notification of an electronicor paper instrument payment, and, optionally, transmit paymentinformation to the service provider computer 110, or any other system,via network interface(s) 157. It will be appreciated that payeecomputer(s) 150 may be implemented as a particular machine, which mayinclude a computer that is designed, customized, configured, orprogrammed to perform at least one or more functions of the payeeapplication module(s) 153, according to an example embodiment of theinvention.

The network 160 may include any telecommunication and/or data network,whether public, private, or a combination thereof, including a localarea network, a wide area network, an intranet, the Internet, a privatenetwork link, a publicly switched telephone network (“PSTN”), a cellularnetwork, and/or any combination thereof and may be wired and/orwireless. The network 160 may also allow for synchronous and/orasynchronous transactions to be transmitted in batch and/ortransactional modes between or among the service provider computer(s)110, the financial institution computer(s) 120, the delivery agentcomputer(s) 130, the subscriber computer(s) 140, and/or the payeecomputer(s) 150. Due to network connectivity, various methodologies asdescribed herein may be practiced in the context of distributedcomputing environments. It will also be appreciated that the network 160may include a plurality of networks, each with devices such as gatewaysand routers for providing connectivity between or among the networks160. Instead of, or in addition to, a network 160, dedicatedcommunication links may be used to connect the various devices inaccordance with an example embodiment of the invention.

Generally, each of the memories and data storage devices, such as thememories 112, 122, 132, 142, 152 and/or any other memory or data storagedevice, can facilitate the storage of data and information, such as datafiles 115, 125, 135, 145, and/or 155, and/or databases 119, 129, 139,149, and 159, for subsequent retrieval. In this manner, the system 100can store various received or collected information in memory, such asin internal data files and/or databases, or external computers andassociated data storage devices operating one or more databasesassociated with and/or operated by one or more of the service providercomputer(s) 110, the financial institution computer(s) 120, the deliveryagent computer(s) 130, the subscriber computer(s) 140, and/or the payeecomputer(s) 150. The memories and other data storage devices can be incommunication with each other and/or other central memories and otherdata storage devices. When needed, data or information stored in memoryor a data storage device may be transmitted to a centralized computerand associated data storage device (e.g., operating a centralizeddatabase) capable of receiving data, information, or data records frommore than one memory or other data storage devices. In otherembodiments, the databases stored in data storage devices shown can beintegrated or distributed into any number of data storage devices. In anexample embodiment, for security, the service provider computer(s) 110,the financial institution computer(s) 120, the delivery agentcomputer(s) 130, the subscriber computer(s) 140, and the payeecomputer(s) 150 may have a dedicated connection to the respectivecomputers and associated data storage devices operating associateddatabases 119, 129, 139, 149, 159, as shown; though, in otherembodiments, the service provider computer(s) 110, the financialinstitution computer(s) 120, the delivery agent computer(s) 130, thesubscriber computer(s) 140, and/or the payee computer(s) 150, or anyother entity may communicate with the computers and associated datastorage devices operating associated databases 119, 129, 139, 149, 159,or any other data storage device via one or more associated DBMS(s)locally or via a network 160. For simplicity, FIG. 1 illustrates thedatabases 119, 129, 139, 149, 159 as separate objects; although it isappreciated that each database is a logical collection of data that isstored on a physical computer and controlled and accessed via a DBMS.Accordingly, each of the databases 119, 129, 139, 149, 159 may be storedin a computer, which may be the respective service provider computer(s)110, the financial institution computer(s) 120, the delivery agentcomputer(s) 130, the subscriber computer(s) 140, and the payeecomputer(s) 150, or may be any other computer.

Suitable processors, such as the processors 116, 126, 136, 146, 156 ofthe service provider computer(s) 110, the financial institutioncomputer(s) 120, the delivery agent computer(s) 130, the subscribercomputer(s) 140, and/or the payee computer(s) 150, respectively, maycomprise a microprocessor, an ASIC, and/or a state machine. According tovarious embodiments, one or more of the computers can be configured as amulti-processor computer having multiple processors 116, 126, 136, 146,156 providing parallel and/or redundant processing capabilities. Suchprocessors comprise, or may be in communication with, media, for examplecomputer-readable media, which stores instructions that, when executedby the processor, cause the processor to perform the elements describedherein. Embodiments of computer-readable media include, but are notlimited to, an electronic, optical, magnetic, or other storage ortransmission device capable of providing a processor withcomputer-readable instructions. Other examples of suitable mediainclude, but are not limited to, a floppy disk, pen drive, flash drive,CD-ROM, DVD, magnetic disk, memory chip, ROM, RAM, EPROM, EEPROM, anyother optical media, any other magnetic tape or other magnetic media, orany other medium from which a computer processor can read instructions.Also, various other forms of computer-readable media may transmit orcarry instructions to a computer, including a router, gateway, privateor public network, or other transmission device or channel, both wiredand wireless. The instructions may comprise code from anycomputer-programming language, including, but not limited to, assembly,C, C++, C#, Visual Basic, Java, Python, Perl, JavaScript, GPSS, LISP,and SAS.

The system 100 shown in and described with respect to FIG. 1 is providedby way of example only. Numerous other operating environments, systemarchitectures, and device configurations are possible. Other systemembodiments can include fewer or greater numbers of components and mayincorporate some or all of the functionality described with respect tothe system components shown in FIG. 1.

Moreover, it will be appreciated that while FIG. 1 illustrates the oneor more service provider computer(s) 110, financial institutioncomputer(s) 120, delivery agent computer(s) 130, subscriber computer(s)140, and payee computer(s) 150 as distinct computers, the functionalityof two or more of those computers may be combined. For example, all ofthe lead time module(s) 111, delivery method module(s) 113, andfinancial institution application module(s) 123 may be provided by asingle computer or system, such as if the financial institution performssome or all of the lead time estimation and delivery methoddetermination functions or if the service provider performs some or allof the check clearing functions. According to another example, the leadtime module(s) 111, delivery method module(s) 113, and payee applicationmodule(s) 153 may be provided by a single computer or system, such as ifthe service provider performs some or all of the payment processingfunctions. According to yet another example, the lead time module(s)111, delivery method module(s) 113, and delivery agent applicationmodule(s) 133 may be provided by a single computer or system, such as ifthe delivery agent performs some or all of the lead time estimationand/or delivery method determination functions. It is appreciated thatthe aforementioned combinations are provided for exemplary purposes, andthat many variations are available without departing from exampleembodiments of the invention.

II. Operational Overview—Estimated Lead Time Processing

Embodiments of the invention can provide for determining estimated leadtimes based upon available mailpiece delivery history informationgathered from various distribution centers that deliver to similargeographical areas. According to one embodiment, estimated payment leadtimes may be used to provide a subscriber with a latest available datefor requesting payment based on a due date for the respective payment.According to another embodiment, estimated lead times may generally beassociated with various payees, based on the geographical area of therespective payees. By associating estimated lead times with payees,subscribers can be provided with estimated receipt dates based on apayment request date. In addition, by associating estimated lead timeswith payees, a service provider can also better understand mailingconstraints when mailing paper instruments on behalf of one or morepayees. Moreover, better understanding the estimated lead timesassociated between various distribution centers and geographical areaspermits a service provider to select a distribution center, consideringthe various parameters, such as, but not limited to, payment due date,payment request date, estimated lead time, delivery costs, availabledelivery methods, and the like. The term “delivery route” is used hereinto generally refer to a route between a given distribution center and agiven destination geographical area (e.g., zip code or othergeographical identifier).

FIG. 2 illustrates a block diagram of an example lead time estimationprocess, according to an example embodiment of the invention. Theoperation of the block diagram of FIG. 2 will be discussed inconjunction with the flow diagrams of FIGS. 3 and 4.

With reference to FIG. 3, a flow diagram illustrates an example method300 by which estimated lead times are determined by one or more serviceprovider computers, such as the service provider computer(s) 110 andlead time module 111 described with reference to FIG. 1, based upon ananalysis of mailpiece delivery history information, according to oneembodiment.

The method 300 begins at block 305, in which delivery historyinformation for one or more mailpieces already delivered is received bythe service provider computer and its lead time module 111. Deliveryhistory information can include any information associated with one ormore mailpieces previously delivered along one or more delivery routes(also referred to herein as “delivery factors”). Delivery historyinformation and associated delivery factors can include informationdirectly associated with the delivery of one or more mailpieces or canbe derived from information associated with cleared checks, postedpayments, payment history information, and the like, as describedherein. Example delivery history information and associated deliveryfactors can include, but are not limited to, distribution centerlocations, delivery agents used, delivery routes taken, delivery costs,and delivery priorities. It is appreciated that delivery historyinformation may represent many other delivery factors, and that anydelivery factor enabling the analysis of delivery practices can be used.

According to one example, delivery history information includesmailpiece delivery status information 210 received from one or moredelivery agent computers, such as via a delivery agent computer 130 andassociated delivery agent application module 133 described withreference to FIG. 1. Because mailpiece delivery status information 210can track any mailpiece, and is not dependent upon what type of accounta given paper instrument is drawn, mailpiece delivery status information210 can be obtained for draft paper instruments drawn on subscribers'accounts and for corporate checks drawn on a service provider's account.Various delivery agents may include, but are not limited to, governmentpostal services (e.g., United States Postal Service, etc.), shipping anddelivery services (e.g., United Parcel Service, Inc., FedEx Corporation,DHL Express, etc.), or in-house delivery services (e.g., operated by aservice provider, operated by a payee, etc.).

For example, the United States Postal Service (“USPS”) provides aservice called OneCode Confirm® (“Confirm”) by which mailpiecesassociated with Intelligent Mail® barcodes (“IMB”) are tracked throughthe delivery route by the barcode, and delivery status information ismaintained by the USPS. Thus, according to one embodiment, the serviceprovider can associate barcodes with paper instruments being mailed toone or more payees that satisfy the Confirm requirements of the USPS(e.g., service identifier or mailer identifier, sender identifier, etc.)as well as providing unique mailpiece and/or delivery geographical areainformation for subsequent use by the service provider (e.g., uniquemailpiece identifier, routing code indicating delivery address and/orzip code, etc.).

Thus, according to one embodiment, the service provider can store thevarious identifiers in memory, such as in a delivery history tableand/or associated with payment history in the database(s) 119 describedwith reference to FIG. 1. Upon receipt of the mailpiece delivery statusinformation 210 from the USPS via the Confirm service, the serviceprovider can update the delivery history table (or any other data storedin memory) based on the delivery status information 210. An update tothe delivery history table may include identifying at least a mailpieceidentifier (which can include a barcode, part of a barcode, or otherwisebe associated with a barcode, or any other unique identifier that may beassociated with a mailpiece) and a receipt date from the delivery statusinformation 210, then updating the corresponding record in the deliveryhistory table with the receipt date. It is appreciated that in someinstances the mailpiece identifier may refer to multiple paperinstruments and thus to multiple payments, such as when multiple paperinstruments are mailed together in a bundle, and the mailpieceidentifier identifies the bundle instead of an individual mailpiece.Moreover, additional data indicating whether the bundle was mailed viaan envelope or via a package may also be stored, because that may impactthe available delivery methods and corresponding estimated lead times,costs, etc. According to one embodiment, the delivery history table caninclude, but is not limited to, the mailpiece identifier (e.g., as partof the barcode or any other unique identifier), the sender identifier(e.g., distribution center 01, distribution center 02, etc.), datemailed and/or date printed (these may be the same or different dates),date received, and a geographical identifier (e.g., 3-digit zip code,5-digit zip code, 9-digit zip code, or 11-digit zip code). An exampledelivery history table is shown in Table I, according to one embodiment;however, any other table structure and data elements may be used.

TABLE I Geographical Mailpiece Sender Mailed/Printed Area (e.g., ZipIdentifier Identifier Date Receipt Date Code) 11111 01 1/10/XXXX1/13/XXXX 98765-0002 11112 01 1/10/XXXX 1/14/XXXX 12345-0001 11254 023/12/XXXX 3/13/XXXX 43212-0023 . . . . . . . . . . . . . . .

According to various embodiments, the service provider may also store apayment history table, for example, in the database 119, which mayinclude additional detailed information associated with payment requestsprocessed by the service provider. The mailpiece identifier (or anyother unique identifier) may be stored or otherwise associated with oneor more corresponding entries in the payment history table, permittingthe service provider to associate the delivery status information 210with the payment history for respective payments and/or to obtain otherdata elements that may be stored or otherwise associated with thepayment history table (e.g., date created, etc.).

According to one embodiment, the delivery status information 210 can betransmitted to the service provider via a periodic batch file process(e.g., daily, twice a day, weekly, etc.) over the network, such as thenetwork 160. However, according to other embodiments, the serviceprovider may be in communication with the Confirm service (or any otherdelivery agent application module 133 of any other delivery agent) overa network and receive the delivery status information 210 electronicallyby various means (e.g., a “pull” or “request” interface, message queues,remote procedure call, a web service, etc.). According to yet otherembodiments, delivery status information 210 can be received andmanually entered into the delivery history table.

While the USPS Confirm service is described in detail, it is appreciatedthat any other delivery agent may also facilitate the tracking ofmailpieces and provide delivery status information 210 by any othermeans. Moreover, while barcodes are described as being used to representone or more unique identifiers for tracking mailpieces, any other uniqueidentifiers and/or technologies may be utilized, such as, but notlimited to, alphanumeric strings, radio frequency identification(“RFID”) technologies, and the like.

According to another embodiment, instead of, or in addition to,receiving delivery status information 210 from one or more deliveryagent computers 130 and associated delivery agent application modules133, the service provider and its associated lead time module 111 canreceive check clearance information 220 to determine delivery times. Asdescribed above, information associated with corporate checks issued bythe service provider and drawn on a service provider's financial accountis ultimately transmitted to the service provider after payments havebeen processed and the corporate checks are cleared. Thus, checkclearance information 220 can be transmitted from one or more financialinstitutions, such as the financial institution computer 120 andassociated financial institution application module 123 described withreference to FIG. 1. According to one embodiment, copies of the actualpaper instruments are provided by the financial institution to theservice provider and contain clearance information printed on orotherwise provided therewith. Check clearance information 220 can bemanually entered (or electronically entered, such as by scanning,optical character recognition processing, etc.) into memory, such as acheck reconcile table stored in the database 119. According to anotherembodiment, where the service provider maintains deposit accounts, oneor more financial institution computers 120 and associated financialinstitution application modules 123 can also transmit electronic fileswith check clearance information 220 to the service provider, thuspermitting electronic entry of check clearance information 220 into thecheck reconcile table. In yet another embodiment, the service providermay analyze payment history information, such as may be stored locallyor requested from one or more payee computers 150 and associated payeeapplication modules 153, to determine check clearance information 220based on the payment history. Check clearance information 220 caninclude, but is not limited to, a check number, a payee, a date created,and a date cleared. According to various embodiments, the checkreconcile table can further include a geographical area identifier(e.g., zip code) like that illustrated in Table I with reference to thedelivery history table. Though, in other embodiments, the geographicalarea information may be obtained based on the payee information, such asin a separate payee table storing payee address information. An examplecheck reconcile table is shown in Table II, according to one embodiment;however, any other table structure and data elements may be used.

TABLE II Geographical Mailed/Printed Area (e.g., Zip Check Number PayeeDate Cleared Date Code) 1234 01 1/15/XXXX 1/17/XXXX 54789-0004 2765 022/12/XXXX 2/13/XXXX 19827-0001 5437 04 4/01/XXXX 4/03/XXXX 54612-0012 .. . . . . . . . . . . . . .

Thus, according to various embodiments, delivery history information canbe obtained at block 305 from one or more delivery agents via deliverystatus information 210 associated with one or more mailpieces and/orfrom one or more financial institutions via check clearance information220 associated with one or more paper instruments mailed by the serviceprovider. According to yet another embodiment, payment receipt orposting information could be received electronically from payees thatare managed payees (i.e., payees that have an existing arrangement withthe service provider and, thus, the ability to electronically transmitpayment information) that have received a paper instrument as a payment.

Following block 305 is block 310, in which the delivery time isdetermined for each mailpiece captured by the delivery historyinformation. According to one embodiment, such as may be performed whenanalyzing delivery status information 210, the delivery time can bedetermined by calculating the number of days occurring between the datea paper instrument is mailed (or printed) and the date the same paperinstrument is received. For example, according to one embodiment, thedelivery time may be calculated as follows: delivery time=datereceived−date printed/mailed−(non-business days or holidays).Non-business days or holidays may be determined in any manner suitablefor each participating entity, such as, but not limited to, maintainingan electronic file or other listing of non-business days or holidaysassociated with each delivery agent, payee, financial institution, orother participating entity.

According to another embodiment, such as may be performed when analyzingcheck clearance information 220, the delivery time can be determined bycalculating the number of days occurring between the date a paperinstrument is mailed (or printed) and the date the same paper instrumentis cleared, subtracting a predefined period of time accounting for thetypical time between receipt date and clearance date (e.g., 1 day). Forexample, according to one embodiment, the delivery time may becalculated as follows: delivery time=date cleared−date printed/mailed−1day−(non-business days or holidays); where the “1 day” is predefined asthe period of time between receipt and clearance. According to otherembodiments, the “date cleared” may be substituted for another timereference during payment processing, such as, but not limited to, datedelivered, date posted or otherwise processed by the payee, etc. Forexample, the delivery time may be calculated differently when usingclearing information instead of delivery information.

According to various embodiments, the service provider or any otherentity may provide one or more non-business day and/or holiday calendarsto identify and account for such days when calculating the delivery timeat block 310. Moreover, because multiple entities associated with thepayment processing may identify non-business days or holidays, the leadtime module(s) 111 may be operable to reference multiple calendars orother listings when calculating delivery times.

Moreover, according to various embodiments, bundled or batched mailingscan be excluded or calculated and maintained independently, sincebundled mailpieces may have different delivery characteristics thansingle mailpieces. As described above, the delivery history table, thecheck reconcile table, the payment table, or any other table, such asmay be stored in the database 119, can include one or more identifiersindicating whether mailpieces were delivered in batch and, if so, howdelivered.

Accordingly, upon identifying the respective delivery times for themultiple mailpieces previously delivered, the delivery times can beassociated with each mailpiece and stored in the respective data tables(or in any other memory).

Following block 310 is block 315, in which the delivery historyinformation is grouped into multiple delivery route groupings. Accordingto various embodiments, the delivery route grouping can be definedaccording to different characteristics. For example, a delivery routegrouping may simply represent delivery mailpieces delivered to the sameor similar geographical areas. Or, in a more specific definition, adelivery route grouping may represent mailpieces delivered to the sameor similar geographical area from the same or similar origination point(e.g., the same distribution center), or a delivery route grouping mayalso consider an indication of the path taken, the delivery methodutilized, and/or any other characteristic that may geographically definepast mailpiece delivery. It is appreciated that the delivery routegrouping can be user definable, permitting flexibility for differentneeds.

According to one embodiment, similar geographic areas may be indicatedby the USPS zip code (e.g., 11-digit type, 9-digit type, 5-digit type,and 3-digit zip code type). The 9- or 11-digit zip code types canidentify a specific delivery address, and thus a single payee. A 5-digitzip code type defines a larger geographic area in which multipleaddresses (i.e., multiple payees) are located. Typically, a 5-digit zipcode reflects a particular post office's delivery territory. A 3-digitzip code type defines an even broader geographic area capturing moreaddresses than the others. As an example, a 3-digit zip code of “200”includes all addresses in the 5-digit zip code of “20008,” whichincludes all the addresses in the 9-digit zip code of “20008-0002” andthe 11-digit zip code of “20008-0002-68.” It is appreciated that USPSzip code conventions are provided for illustrative purposes only, andthat any other postal code or address identifier may be used to definegeographical areas. The delivery times determined at block 310 can thusbe grouped into delivery route groupings defined according to variouslevels of granularity, based upon the geographical area identifier usedto define the delivery route. For example, according to one embodiment,delivery times can be grouped by delivery routes defined by one or moreof the 11-, 9-, 5-, and 3-digit zip code types, such that the zip codetype used to identify the grouping will determine the level ofgranularity. As one example, using a 5-digit zip code type will providea more granular delivery route grouping (smaller delivery area) than a3-digit zip code type (capturing a greater area by encompassing multiple5-digit zip codes).

Following block 315 is block 320, in which the delivery times can beanalyzed by the lead time module 111 for each respective delivery routeto determine an estimated lead time for each delivery route. As anexample, the service provider may have at least two distribution centersfrom which it mails paper instruments to payees. Thus, for eachgeographical area at least two delivery routes may be analyzed—one froma first distribution center to the geographical area, and a second fromthe second distribution center to the same geographical area. It isappreciated that any number of delivery routes to a given geographicalarea can be provided (e.g., more than two distribution centers mailingto the same zip code), though, two are used herein for exemplarypurposes.

When analyzing delivery time information, various factors can beconsidered before arriving at the final estimated lead time for eachdelivery route. For example, the stored delivery times can be analyzedto determine whether there is sufficient volume of delivery historyinformation collected over a given period of time to provide meaningful,accurate, reliable estimated lead times. In another example, thedistribution of delivery history information can be analyzed andpre-processed to identify outliers in the data history and to avoidexcessive variance in the delivery time data captured. In anotherexample, seasonal variation, such as busier mailing activities duringcertain periods in the year (e.g., holidays, tax time, etc.), can beaccounted for.

According to one embodiment, one aspect of the analysis performed atblock 320 may include determining whether there is sufficient volumeover a certain period of time. In one example, the lead time module 111may be configured to require a certain number of calculated deliverytimes for each delivery route within a predefined number of days (e.g.,at least 1,000 data points over the past 30 days, or an average of 1,000data points each month for the past four months, or at least 200 datapoints per week for the past four weeks, etc.). It is appreciated thatvarious considerations and conditions may be accounted for andconfigured into the lead time module 111 to determine what volume ofdata would provide meaningful results or a desired confidence level. Inone example, different requirements may exist for relying on differentdelivery route groupings (e.g., selecting between 3-digit, 5-digit,9-digit, or 11-digit zip codes). Moreover, any of the parameters andcharacteristics can be reviewed and easily changed over time, dependingupon the need, and can vary between processing tasks.

According to another embodiment, one aspect of the analysis performed atblock 320 may include analyzing the distribution of data pointsgathered. For example, after determining that there is a sufficientvolume of data, the lead time module 111 may be configured to perform astatistical analysis on the delivery time data to determine whether thedelivery time data may provide an estimated lead time within a desiredconfidence level. The lead time module 111 can be configured to performvarious statistical and distribution analysis techniques, including, butnot limited to, chi-square analysis, mode analysis, mean analysis, MonteCarlo analysis, and the like. For example, according to one embodiment,the mode of all delivery time data captured may be used if the number ofdelivery time data points with a value less than or equal to the modeamounts to at least X % of the total number of delivery time data points(where X % can be varied, based on the level of confidence desired). Itis appreciated that these analysis techniques are provided forillustrative purposes, and that any analysis techniques may be performedby the lead time module 111 to estimate, predict, or otherwise identifylead times, according to other embodiments of the invention. Moreover,the parameters used, such as the confidence level, the number of datapoints, etc., can be altered over time, and can vary between processingtasks

The lead time module 111 can be configured to perform the estimated leadtime analysis at block 320 in response to various triggering events.According to one embodiment, the estimated lead time analysis can beperformed periodically, such as bi-weekly or monthly. According toanother embodiment, the estimated lead time analysis can be performed ona rolling basis, such that it is constantly (or on a more frequentbasis) performing the analysis and updating the estimated lead times.According to yet another embodiment, the lead time module 111 can beconfigured to perform the estimated lead time analysis upon receiving apredefined new volume of delivery history information (e.g., from one ormore delivery agents and/or financial institutions) for a given deliveryroute.

According to one embodiment, the delivery time data for a singlemailpiece can be associated with multiple delivery routes at differinglevels of granularity, such as by grouping delivery times by 5-digit zipcode types as well as 3-digit zip code types. While delivery times maybe grouped by 9- or 11-digit zip codes, doing so presumably may captureonly a single recipient.

Accordingly, upon performing the analysis at block 320, the serviceprovider can identify an estimated lead time for each delivery route.The estimated lead times for each delivery route can be stored in ageographical area table, such as in the database 119, identifying theestimated lead times per delivery route for each geographical areaanalyzed. An example geographical area table is shown in Table III,according to one embodiment; however, any other table structure and dataelements may be used.

TABLE III Geographical Area Distribution Center Distribution Center(e.g., Zip Code) 01 Est. Lead Time 02 Est. Lead Time . . . 12344 2 days5 days . . . 12355 3 days 5 days . . .  123 2 days 5 days . . . 56789 4days n/a . . . . . . . . . . . .

According to various other embodiments, the estimated lead times storedin the geographical area table (or any other data structure) can besegmented according to various other factors. Example factors mayinclude, but are not limited to, delivery agent used, delivery methodused, time of day mailed, day of week mailed, and the like. For example,with reference to Table III, assuming that at least three deliveryagents are possible, there may be at least three entries for thedelivery route between each zip code and distribution center (e.g.,distribution center 01 to zip code 12344 could have three estimated leadtimes, one for each of the three possible delivery agents). It isappreciated that the number of factors applied to segment estimated leadtime data can vary in each embodiment, and may be configurable by theservice provider or may be influenced by the options available torespective subscribers, payees, payment request types, etc. (e.g., onlycertain subscribers may be permitted to have the service provider useexpedited delivery methods, etc.). Various delivery methods andadditional factors associated therewith are described in more detailwith reference to FIGS. 6 and 7 below.

In addition, depending upon the grouping used to define the deliveryroute, the estimated lead times calculated for one grouping may bedifferent than the other grouping. Thus, the lead time module 111 can beconfigured to perform conflict resolution when determining whichestimated lead time to apply. According to one example, the lead timemodule 111 can be configured to accept a more granular grouping (e.g.,use the estimated lead time calculated by grouping based on a deliveryroute defined to a 5-digit zip code type as compared to one defined to a3-digit zip code type), because that may be more indicative of anydelivery characteristics specific to that particular area. According toanother example, the lead time module 111 can be configured to accept alarger grouping if the smaller grouping does not have a sufficientvolume of delivery time data (e.g., not enough previous mailpiecesdelivered to the 5-digit zip code to provide the desired level ofconfidence).

Following block 320 is block 325, in which estimated lead times canoptionally be associated with payees based on their geographicallocation and/or other factors. According to one embodiment, after havingdetermined the estimated lead time for each respective delivery routeanalyzed at block 320, estimated lead times can be associated withdifferent payees to whom the service provider mails paper instrumentsbased on the geographical area of each respective payee, and stored in apayee estimated lead time table in memory, such as in the database 119,and/or stored in or associated with any other table (e.g., payee table,etc.). Creating a payee estimated lead time table can permit the serviceprovider to display estimated lead times to subscribers, such as may bepresented in an electronic bill presentment and payment application, asfurther described with reference to FIGS. 4A-4B and 5A-5C. A payeeestimated lead time table can also permit the service provider to betterschedule printing and mailing of paper instruments upon receipt of apayment request transaction. Additional details of associating anestimated lead time with one or more payees is described in more detailwith reference to FIGS. 4A-4B.

The method 300 can end after block 325, having processed deliveryhistory information to analyze delivery times and determine estimatedlead times for various delivery routes. It is appreciated that thevarious steps illustrated by the blocks in FIG. 3 do not have to beperformed together or by a single software module, but instead may beperformed via multiple separate processes. For example, delivery historymay be received at block 305 as a function of receiving or “pulling”information from an external party, while determining delivery time foreach mailpiece at block 310 may be performed in conjunction with thestep at block 305 or in conjunction with grouping delivery history andtime information into delivery route groupings at block 315. Moreover,one or more of these functions may be performed as a result of a time orsequential trigger, or as a result of a predefined volume of data beinggathered.

Turning to FIGS. 4A-4B, after estimated lead times have been determined,the one or more service provider computer(s) 110 and associated leadtime module 111 can associate estimated lead times 230 with payees, suchas to permit presenting the information to subscribers or otherwiseusing the information during payment processing, according to oneembodiment of the invention. Estimated lead times 230 can be presentedand/or used when presenting payment options to subscribers, such as whenthe subscriber application module 143 is utilized to interface with anelectronic bill presentation and payment application provided by theservice provider. For example, by using a more accurate estimated leadtime, a service provider can indicate, for payment to a particularpayee, an earliest possible payment receipt date or, conversely, alatest possible payment request submission date to ensure paymentreceipt by a certain date. Or in another example, a service provider candisplay the estimated lead times 230 (or delivery times) for a list ofpayees. According to various embodiments, these and other features canbe made available by a service provider based at least in part on theestimated lead times calculations as described with reference to FIG. 3.

Still with reference to FIGS. 4A-4B, the method 400 begins at block 405,in which the lead time module 111 can identify at least one payee towhich an estimated lead time can be associated. According to oneembodiment, a value based on an estimated lead time associated with apayee may be presented responsive to receiving a request from asubscriber interfacing with an electronic bill presentment and paymentapplication for a particular transaction user interface (e.g., a requestto add a new payee or submit a new payment request). According toanother embodiment, one or more payees may be identified independent ofa subscriber's request, but as a result of asynchronously processingmailpiece delivery history information for associating one or moreestimated lead times apart from processing a particular payment, such asis described with reference to block 325 of FIG. 3. Accordingly, atblock 405, the lead time module 111 of the service provider may identifyone or more payees with which an estimated lead time is to beassociated.

Following block 405 is block 410, in which the lead time module 111 isoperable to determine at least one delivery route associated with thepayee(s) identified at block 405. As described, the delivery routes aredefined by the distribution center and the geographical area associatedwith the delivery address. According to one embodiment, the lead timemodule 111 can be configured to retrieve payee delivery addressinformation from previously stored payee information, such as in managedpayee data or the subscriber's personal payee data stored in thedatabase 119 described with reference to FIG. 1. According to anotherembodiment, payee delivery address information can be provided as partof the payment request received from the subscriber. According to otherembodiments, payee information, such as delivery address information,can be retrieved from any other data source, including, but not limitedto, from the subscriber, directly from the payee, from a financialinstitution associated with the payee or subscriber, or from a thirdparty source. Upon retrieving the payee's delivery address information,the geographical area, and thus the various available delivery routes,associated with the delivery address can be determined. If the deliveryroutes are defined by zip code, the payee's zip code can be extracted toidentify the payee's geographical area. In other embodiments, thegeographical area may be defined differently, such as any other addressidentifier.

Upon identifying the payee's corresponding geographical area, at leastone delivery route can be identified for the payee. According to variousembodiments, one or more delivery routes to the payee's geographicalarea exist, for example, between one or more distribution centers (orother sender locations) and the payee's zip code. As an example, withreference to Table III above, two delivery routes to zip code 12344exist—a first delivery route from Distribution Center 01, and a seconddelivery route from Distribution Center 02. In other examples, only onedelivery route may exist, such as if only one distribution center mailsto a given geographical area. In yet other examples, more than twodelivery routes may exist, such as if there are more than twodistribution centers available for mailing to a given geographical area.According to other embodiments, as described more fully with referenceto FIGS. 6 and 7, different delivery methods may also be identified atblock 410, which may affect the delivery route and/or the estimated leadtimes determined (e.g., different available delivery agents, differenttransportation means, different priority services, alternate deliverypaths, etc.).

After having determined the delivery route(s) associated with each payeeat block 410, block 415 follows, in which estimated lead times for eachdelivery route are retrieved, as described with reference to FIG. 3.

Following block 415 is decision block 420, in which it is determinedwhether multiple delivery routes were identified at block 410 as beingavailable for delivery to the payee(s) identified. If multiple deliveryroutes are identified for a payee, then block 425 follows, in which thedesired delivery route is selected from those identified. According toone embodiment, the lead time module 111 can be configured to select thedelivery route associated with the shortest estimated lead time as thedesired delivery route.

Having determined the desired delivery route at block 425, block 430follows in which the estimated lead time associated with the desireddelivery route is associated with the respective payee. In addition, ifit is determined at decision block 420 that only a single delivery routeis available for delivery to the payee(s) identified, then block 430follows. According to one embodiment, the lead time module 111 can beconfigured to associate the estimated lead time for the desired deliveryroute selected at block 425 with each of the respective payeesidentified. The lead time module 111 may store the association inmemory, either temporarily, such as if only for transmitting orotherwise presenting to a subscriber, or for longer durations, such asif storing the association in a database, such as the payee table or thepayee estimated lead time table in the database 119, or otherwiseassociated with managed payee or personal payee data, for subsequentaccess.

Following block 430 is decision block 435, in which it is determinedwhether the estimated lead time processing performed is in response to auser interface request (e.g., from a subscriber) or as a result ofasynchronous processing.

If it is determined at decision block 435 that the lead time processingis being performed in response to a user interface request, then block440 follows, in which the information is presented via a user interface.Otherwise, block 445 follows, in which the estimated lead timeassociations with the payee(s) are stored.

In response to a user interface request, block 440 follows, in which thepayee estimated lead times 230 associated with one or more of thepayees, or one or more values based on the lead times, are transmittedor otherwise presented to a subscriber, such as presented via a userinterface, as described in more detail with reference to FIGS. 5A-5C. Asdescribed, estimated lead times for one or more payees can be determinedresponsive to a variety of user interface requests. Thus, estimated leadtimes can be transmitted or otherwise presented to a subscriber in anumber of ways, examples of which are described herein.

According to one embodiment, upon accessing a user interface of anelectronic bill presentment and payment application displaying a list ofone or more payees associated with the subscriber (e.g., a payee list),an estimated lead time is presented for each payee in the list at block440. For example, when generating the user interface containing the listof one or more payees, the steps of the method 400 can be performed bythe lead time module 111 for each payee, and the resulting estimatedlead time for the desired delivery route can be presented to thesubscriber at block 440. Thus, upon accessing the list of one or morepayees, data indicating an estimated lead time (e.g., “n days fordelivery”, etc.) is presented in association with each payee. Such alist could be presented when processing an “add payment” request forpayees already associated with the subscriber. A similar list can begenerated and presented as a pick list (e.g., containing managedpayees), for example, to permit a subscriber to “add a payee” to thesubscriber's list or to otherwise select a managed payee.

According to another embodiment, as a subscriber is selecting orotherwise adding a new payee to a list of payees associated with thesubscriber via an electronic bill presentment and payment application,the estimated lead time could be presented to the payee via a userinterface. For example, each time a new payee is selected by asubscriber via a user interface, the steps of the method 400 can beperformed by the lead time module 111 for the newly selected payee, andthe resulting estimated lead time for the desired delivery route can bepresented to the subscriber at block 440. Thus, upon identifying a newpayee, data indicating the estimated lead time (e.g., “typical estimateddelivery time is n days”) is presented in association with the newlyselected payee.

According to various aspects of these and other embodiments, additionaldata associated with the payment request may be used when determiningthe estimated lead time to present to the subscriber. For example, apayment date associated with the payment request may be determined basedupon the estimated lead time. In example embodiments, the payment datecan be a due date or a process date. If the payment date is a due date,the earliest due date for an on-time payment can be determined based on(1) today's date+(2) the estimated lead time+(3) any non-businessdays/holidays. If the payment date is a process date and the due datecan be identified (e.g., by an electronic bill), then the process datecan be set to the latest date that would allow the payment to get therein time, such as (1) the due date−(2) the estimated lead time−(3) anynon-business days/holidays.

According to various other embodiments, estimated lead times forrespective payees can be presented to a subscriber at block 440 by anyother number of techniques. Other example techniques include, but arenot limited to, providing an audio response over a telecommunicationsnetwork (or any other network) via an integrated voice response unit(“IVR”) session, presenting a message to a customer service agent forrelaying to a subscriber during a live customer service call session,transmitting via an email (or other network-based message), transmittingvia a short messaging service (“SMS”) message, printing on bills,printing on reminders, and the like.

If, however, it is determined at decision block 435 that the estimatedlead time processing is not being performed in response to a userinterface request (e.g., it is being performed as part of asynchronousprocessing), then block 445 follows. At block 445, a payee estimatedlead time table (or other representative data) can be generated forstoring estimated lead time data in association with one or more payeesindependent of receiving a subscriber's payment request transaction orbill presentation request. For example, estimated lead time data may beassociated with the respective payee and stored in an estimated leadtime table for storage in a database, such as the database 119 describedwith reference to FIG. 1.

Some or all of the steps illustrated for this example method 400 can beperformed to asynchronously prepare and store estimated lead time datain association with multiple payees. According to this embodiment, atblock 405, one or more payees for which estimated lead times are to beassociated can be identified independent of any subscriber request. Forexample, payees (or other mailpiece recipients) can be retrieved from adatabase, such as from a payee table, and corresponding addressinformation compared to the geographical area table for determiningavailable delivery routes and corresponding estimated lead times foreach of the identified payees. Thus, according to one embodiment, apayee estimated lead time table can include, but is not limited to,payee identifier, payee geographical area (e.g., zip code(s), otheraddress information, etc.), available delivery routes, and estimatedlead times for each available delivery route. In various embodiments,the desired delivery route may be selected for each payee and stored inthe payee estimated lead time table; though in other embodiments, thedesired delivery route is not selected until analyzed with respect to aspecific transaction or inquiry.

A payee estimated lead time table can further permit a service providerto make more informed decisions on delivery methods used for each payeewhen mailing a paper instrument, such as choosing cost effectivedelivery routes, quickest delivery routes, cost effective deliveryagents, quickest delivery agents, and the like. Similarly, according toone embodiment in which delivery history information for bundledmailpieces is analyzed separately from that for individual mailpieces, aservice provider may perform an analysis to determine under whichcircumstances it may be desirable to group paper instruments for bundleddelivery instead of individual delivery (e.g., a certain volume ofmailpieces along a given delivery route may be quicker and/or more costeffective than individual delivery).

Similarly, according to yet another embodiment, instead of, or inaddition to, transmitting estimated lead time information to asubscriber at block 440, estimated lead time information 240 can betransmitted or otherwise accessed by a delivery method module 113 of theservice provider for analysis when selecting among various availabledelivery methods, as described in more detail with reference to FIGS. 6and 7. Moreover, the functions of selecting a preferred delivery methodfrom various available delivery methods may be coordinated withcalculating the estimated lead time module, such that the methods 300and 400 described with reference to FIGS. 3 and 4 are performed with themethod 700 described with reference to FIG. 7.

The method 400 can end after blocks 440 or 445, having associatedestimated lead times with one or more payees based on a desired deliveryroute for delivery to the respective payees and based on lead timeestimations performed by analyzing previously delivered mailpieces tothe same or similar geographical areas.

Turning to FIGS. 5A-5C, example user interfaces for presenting estimatedlead time data to a subscriber are illustrated. These interfaces areprovided for exemplary purposes only, and many other interfaces may begenerated and provided to a subscriber when conducting a transactionwith a service provider via an electronic bill presentment and paymentapplication. The user interfaces illustrated by FIGS. 5A-5C and furtherdescribed herein can be displayed by a subscriber's computer, such as asubscriber computer 140 and associated subscriber application module 143described with reference to FIG. 1. More specifically, the userinterfaces may be generated for transmitting to a subscriber's computerover a network, such as the Internet, and displayable in an Internetbrowser. However, according to various other embodiments, other meansfor transmitting and presenting a user interface may be employed, suchas, but not limited to, via SMS messages, via emails, and the like.According to one embodiment, transaction request and estimated lead timedata (and/or other data) are transmitted over a network between thesubscriber's computer and the service provider computer, such as todetermine estimated lead times by the service provider and to transmitthe same for display to the subscriber via a user interface. Though,according to other embodiments, estimated lead time processing can be atleast partially performed locally on the subscriber's computer, such asby initially sending geographical area lead time data and/or payee leadtime data to the subscriber's computer for subsequent local processingin association with a transaction request or other input by thesubscriber.

With reference to FIG. 5A, an example add payee user interface 510displaying an “add payee” feature including a payee pick list andassociated estimated lead times is illustrated, according to oneembodiment. Among other features, the payee list user interface 510 caninclude an add payee list 511 listing payees 512 that can be selected(e.g., managed payees) and an estimated payee lead time 514 associatedwith each of the payees 512 in the add payee list 511. Accordingly, upona subscriber accessing the add payee user interface 510 via anelectronic bill presentment and payment application, the serviceprovider and its associated lead time module 111 can display payees andassociated estimated lead times, as described in more detail withreference to FIGS. 3 and 4, for example. Upon selecting a payee from theadd payee pick list 511, a next user interface for continuing the addpayee function (e.g., retrieving customer account number, etc.) can beaccessed with pre-populated information, such as, but not limited to,the selected payee information and estimated lead time.

FIG. 5B illustrates an example payment request user interface 530displaying a summary list of one or more unpaid bills and respectivepayees, indicating an estimated lead time associated with each payee,and providing additional fields for entering payment request transactiondata, according to one embodiment. The payment request interface 530 caninclude a payee list 532 and associated payee estimated lead times 534.The payment request interface 530 can further include an amount entryfield 536 (e.g., text box, drop down box, selectable field,auto-populating field, etc.), a due date field 538 (pre-populated in oneembodiment, otherwise capable for user entry), and a payment date entryfield 540 (e.g., text box, drop down box, selectable field, calendarselection, auto-populating field, etc.) indicating the date payeereceives payment.

The amount entry field 536 may default to the amount indicated byelectronic versions of each of the indicated bills. In one embodiment,as illustrated, the amount entry field 536 may be capable of accepting asubscriber entry, permitting the subscriber to adjust the amount to bepaid for each of the indicated payments. Similarly, the due date field538 can be automatically populated by the system, based on a due dateindicated in electronic versions of each of the indicated bills.However, in other embodiments, the due date field 538 may be capable ofaccepting a subscriber entry, such as if electronic bill data isunavailable, permitting the user or subscriber to indicate the due dateof the bill being paid, which will in turn be analyzed to cause anautomatic population of the payment date entry field 540.

According to various embodiments, the payment date entry field 540 canbe based at least in part on the value indicated in the due date field538 and the estimated lead time field 534. For example, in oneembodiment, the date indicated in the due date field 538 can cause theautomatic population of the payment date entry field 540 with a defaultvalue indicating the latest possible payment processing date based onthe estimated lead time 534 associated with that payee (e.g., paymentdate=due date−estimated lead time−(non-business days or holidays)).Thus, the payment request user interface 530 indicates to a subscriberwhat the latest available payment processing date is for a particularpayee based on the estimated lead time data and the due date.

Thus, according to one embodiment, the payment date entry field 540 candefault to an automatically calculated latest payment processing datefield (based on the due date for the respective bill and the estimatedlead time for the corresponding payee). The payment date entry field 540can also be capable of accepting a subscriber entry, such that asubscriber may override the default payment processing date. In oneembodiment, the payment request user interface 530 may prevent asubscriber from entering a date later than the calculated latest paymentdate (based on the due date for the respective bill and the estimatedlead time for the corresponding payee). For example, a calendarselection field may only have dates equal to or earlier than thecalculated latest payment processing date, or a text box may generate anerror message or warning indicating when a selected date is after thecalculated latest payment processing date. In other embodiments,however, the payment request user interface 530 may permit a subscriberto enter a later date, though, a warning or other message may begenerated indicating that the date is after the calculated latestpayment date and that the payment may not be completed on or before thedue date.

With reference to FIG. 5C, another example payment request interface 550is illustrated, according to one embodiment. As illustrated by thisembodiment, the payment request interface 550 can include a payee list552, associated estimated lead times 554, and amount entry fields 556,similar to that described with reference to FIG. 5B. Though, accordingto this embodiment, an estimated payment date field 558 is operable todisplay estimated payment dates 560 indicating the earliest estimatedpayment dates for each payee based on the estimated lead times 554 andthe current date (e.g., estimated payment date>=current date+estimatedlead time+(non-business days or holidays)). In one example embodiment,the estimated payment date field 558 can be edited by the user, suchthat only days that are on or after the earliest estimated payment datecan be entered (or otherwise selected, such as from a selectablecalendar function, etc.) for populating the estimated payment date field558. Thus, according to this embodiment (and that illustrated by FIG.5B), the payment request interface 550 permits a subscriber to morestrategically schedule payments based on estimated lead times. Doing socan allow a subscriber to more effectively manage account balances, timepayment dates, avoid late payments, and the like. It is appreciated thatwhile the entry field is described as a text entry field, according toother embodiments, any entry field can be provided (e.g., selectablecalendar, drop down box, selectable field, date field, etc.).

According to various embodiments, the estimated lead time date presentedto a subscriber via a user interface can further be adjusted by the leadtime module 111 to factor for various delays and/or processing overheadprior to presenting via the user interface. Example factors that may beconsidered include, but are not limited to, time of day (e.g., paymentrequest entered late in the day may consider the next day as the paymentmail date), service provider processing overhead (e.g., service providervolume, printing delays, etc.) that may delay printing and mailing apaper instrument, busy periods (e.g., holiday mailing delays, taxseason, etc.), payee delays (e.g., certain payees may not processpayment until the day after receipt), and the like. Accordingly, as partof the estimated lead time processing described with reference to FIGS.3 and 4 and/or as part of the generation and presentation of one or moreuser interfaces described with reference to FIGS. 5A-5C, additional timemay be added to estimated lead times presented and/or estimated paymentdates calculated.

In one example, estimated lead times may be used by a service providerafter determining that a payment request requires a paper instrument beprinted and mailed instead of being issued electronically, which mayoccur after a subscriber enters the payment request via a userinterface. For example, a service provider may begin payment processinga predefined number of days before a target due date, or on a processdate designated by the subscriber. Accordingly, by understanding thebest estimated lead time, a service provider can identify whether thereis variability in the payment schedule, which may allow holding apayment, print scheduling, and the like.

In one example, after a payment request has been submitted to theservice provider, additional lead time processing can be performed todetermine which day of the week to print and mail paper instrumentsbased on the frequency of processing and the lead time. Accordingly, theservice provider can schedule printing and/or mailing on certain days ofthe week. In one example, a printing/mailing schedule can be generatedbased at least in part on the estimated lead time analysis, againstwhich the lead time module 111 can compare a subscriber's paymentrequest when scheduling the printing and/or mailing of the correspondingpaper instrument(s). Various other processing may be performed by theservice provider upon receiving a payment request from a subscriber.

III. Operational Overview—Delivery Method Selection

Other embodiments of the invention may provide for selecting one ofmultiple available delivery methods for mailing one or more mailpiecesto a recipient, based at least in part on delivery history informationfor mailpieces delivered to the same geographical area as the recipientin a manner similar to that described above. For example, according toan embodiment in which the mailpiece recipient is a payee, the variousdelivery methods available for delivering the mailpiece to the payee areidentified. Each delivery method can be characterized at least in partby one or more of the distribution centers from which the paperinstrument is to be mailed (e.g., the delivery route as described withreference to FIGS. 3-4), the delivery agent used for delivery (e.g.,USPS, UPS, FedEx, DHL, in-house transportation, etc.), or any otherfactor distinguishing the various available delivery methods (e.g.,transportation means, priority services, etc.). In addition to themechanics for effecting delivery, additional data can be associated witheach available delivery method, such as an associated calculatedestimated lead time, to further facilitate a service provider inselecting a delivery method. Other additional data and factors can beconsidered when selecting a preferred delivery method for deliveringmailpieces to the payee, such as, but not limited to, delivery costs,subscriber status and access to various delivery methods, existingrelationship and arrangements with various delivery agents, distancetraveled, etc. Upon selecting a preferred delivery method, anassociation can be stored or otherwise maintained between the payee andthe selected delivery method, permitting the service provider toretrieve and/or analyze this information when performing subsequentdelivery processing for the given payee.

FIG. 6 illustrates a block diagram of an example delivery methodselection process, according to an example embodiment of the invention.The operation of the block diagram of FIG. 6 will be discussed inconjunction with the flow diagram of FIG. 7. It is also appreciatedthat, according to one embodiment, the method 700 can be performed inassociation with the example method 400 such that some of the steps maybe shared between the methods. For example, the available deliveryroutes and delivery methods may be determined concurrently, after whichthe additional factors are determined and analyzed to select thepreferred delivery methods and present estimated lead times.

With reference to FIG. 7, a flow diagram illustrates an example method700 by which a delivery method is selected from multiple availabledelivery methods by one or more service provider computers, such as theservice provider computer 110 and its delivery method module 113described with reference to FIG. 1, based upon delivery methodcharacteristics and factors, according to one embodiment.

The method 700 begins at block 705, in which at least one payee isidentified by a service provider as being a recipient or a potentialrecipient of a mailpiece, such as a paper instrument mailed as paymenton behalf of a subscriber. One or more payees can be identified at block705 under a variety of circumstances, including responding to a userinterface request, or a batch process performed asynchronously andindependent of any subscriber activity, such as when selecting adelivery method for multiple payees (like that described with referenceto FIGS. 4A-4B). Moreover, in one example, a delivery method may beselected when a payment is being processed by a service provider (orother entity) and after a subscriber has requested payment via a userinterface, so as to permit the service provider (or other entity) toidentify the delivery method for the given situation.

Following block 705 is block 710, in which the geographical areaassociated with the payee is identified for delivery. In associationwith determining that a paper instrument is to be printed and mailed,the service provider can retrieve delivery address informationassociated with the payee to identify the geographical area (e.g., zipcode, as discussed in detail with reference to FIG. 3) where the paperinstrument is to be delivered, in a manner similar to that describedwith reference to block 410 of FIG. 4A, for example.

Following block 710 is block 715, in which the delivery methodsavailable for delivering to the payee's geographical area areidentified. For example, for a given geographical area, multipledifferent delivery methods may be available, based on one or more of:different delivery routes (e.g., different distribution centers formailing to the same geographical area), different delivery agents,different delivery transportation means (e.g., ground, air, freight,etc.), single or bulk mailings, and/or different delivery priorityservices (e.g., same day, next day, standard, etc.). According to oneembodiment, the service provider may store available delivery methodsassociated with different geographical areas in memory, such as in adelivery method table in the database 119. An example delivery methodtable can include, but is not limited to, geographical area identifiers(e.g., zip codes) and the available delivery methods for delivery toeach of the geographical areas. An example delivery method table isshown in Table IV, according to one embodiment; however, any other tablestructure and data elements may be used.

TABLE IV Del. Agent Del. Agent Del. Agent Del. Agent Del. Agent 01 -Ground 01 - Air 02 - Ground 02 - Air 02 - Priority Ground geo. areaDist. Dist. Dist. Dist. Dist. Dist. Dist. Dist. Dist. Dist. (e.g., zipCent. Cent. Cent. Cent. Cent. Cent. Cent. Cent. Cent. Cent. . . . code)01 02 01 02 01 02 01 02 01 02 . . . 12344 X X X X X X X X X . . . 12355X X X X X X X X X . . .  123 X X X X X X X X X . . . 56789 X X X X X . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ..

As illustrated by Table IV, different geographical areas may havedifferent delivery methods available. In the example illustrated byTable IV, the service provider does not utilize distribution center 02to deliver to the 56789 zip code. As another example, the priorityground service by the delivery agent 02 is not available from thedistribution center 02 for the 3-digit zip code of 123, and thus not forzip code 12344 or 12355. It is appreciated that any number ofcombinations of delivery methods may be available, and that Table IV isprovided for illustrative purposes only. Moreover, it is appreciatedthat the data as presented in the delivery method table may be combinedwith other data in one or more other tables, such as estimated leadtimes data, delivery cost data, and the like. For example, instead ofindicating availability or non-availability, an estimated lead timevalue could be populated only for those available combinations, anestimated cost associated with the delivery method combination could beincluded, or any combination of these or other data that may facilitateselecting a delivery method.

Thus, according to one embodiment, the delivery method module 113 can beconfigured to retrieve from the delivery method table (or any other datastored in memory) which delivery methods are available for delivering apaper instrument to the payee's geographical area identified at block710.

It is appreciated that, while different delivery methods are describedin detail as differing by at least one of a delivery route, a deliveryagent, transportation means, or priority service, delivery methods canvary by any number of characteristics, according to various embodiments.Accordingly, when identifying delivery methods, such as at block 715,and/or when selecting between multiple available delivery methods, suchas is described below, delivery methods are not limited to theillustrative variations described herein.

Following block 715 is decision block 720, in which it is determined ifmultiple delivery methods are available for the payee. If there are, theprocessing continues to blocks 725 through 750 to select a desireddelivery method from the multiple available delivery methods. However,if it is determined at decision block 720 that only one delivery methodis available for the payee, then processing skips to block 750 in whichthe only available delivery method is associated with the payee.

Accordingly, if multiple delivery methods are available, block 725follows, in which the estimated lead times associated with each of theavailable delivery methods are received, according to one embodiment. Inone embodiment, the delivery method module 113 is configured to receiveestimated lead time data 610 from the lead time module 111. According toanother embodiment, a delivery method estimated lead time table can beobtained from a database, such as the database 119, for storingestimated lead time data with each delivery method. According to anotherembodiment, the delivery method table, such as is illustrated by TableIV above, can be updated or otherwise altered to also include estimatedlead time data associated with each of the delivery methods for each ofthe delivery routes. According to another embodiment, instead of, or inaddition to, updating the delivery method table, the geographical areatable, such as is illustrated by Table III above, can be updated orotherwise altered to include the additional delivery methods (e.g.,additional entries for each of the different delivery methodcombinations, such as agent, transportation means, priority services,etc.). Thus, when initially determining the estimated lead time data, asdescribed with reference to FIG. 3, the lead time module 111 and/or thedelivery method module 113 can organize and associate the estimated leadtime data according to the various delivery methods. An example deliverymethod estimated lead time table is shown in Table V, according to oneembodiment; however, any other table structure and data elements may beused.

TABLE V Del. Agent Del. Agent Del. Agent Del. Agent Del. Agent 01 -Ground 01 - Air 02 - Ground 02 - Air 02 - Priority Ground Geo. AreaDist. Dist. Dist. Dist. Dist. Dist. Dist. Dist. Dist. Dist. (e.g., ZipCent. Cent. Cent. Cent. Cent. Cent. Cent. Cent. Cent. Cent. . . . Code)01 02 01 02 01 02 01 02 01 02 . . . 12344 3 5 2 2 3 4 2 2 2 . . . 123553 5 2 2 3 4 2 2 1 . . .  123 3 6 2 2 3 4 2 2 2 . . . 56789 4 1 2 2 3 . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ..

Following block 725 is block 730, in which any additional factorsassociated with each of the available delivery methods are optionallydetermined and stored for subsequent analysis when selecting a preferreddelivery method. For example, in a manner similar to that performed todetermine estimated lead times, the delivery method module 113 can beconfigured to track and store additional delivery method factors 620associated with the delivery history information corresponding to thesame or similar delivery methods for the same delivery route (e.g.,multiple previously delivered mailpieces that were delivered to the samegeographical area via the same delivery methods). According to variousembodiments, additional delivery method factors 620 can include, but arenot limited to, delivery agent costs, distribution center costs, otherdelivery costs, availability of delivery agents, availability ofdelivery methods based on the corresponding subscriber's status (e.g.,certain subscribers may not be permitted to utilize expedited deliveryservices based on the service level the subscriber is paying for, etc.),availability of delivery methods based on the corresponding payee'sstatus (e.g., certain payees may not accept delivery via certaindelivery methods, etc.), prior arrangements with delivery agents (e.g.,volume discounts, priority agreements, etc.), time of day, day of week,seasonal delivery trends, and the like. It is appreciated that theaforementioned additional delivery factors are provided for illustrativepurposes, and that any additional factor, characteristic, parameter, orrequirement may be considered when selecting a preferred deliverymethod, according to various embodiments.

According to one embodiment, one or more additional delivery methodfactors 620 are stored and maintained by the service provider (e.g.,associated with account data, financial data, payee data, third partycontracting terms, etc.), and can be retrieved by the delivery methodmodule 113 at block 730. Though, according to other embodiments, thedelivery method factors 620 may be retrieved by the delivery methodmodule 113 from other sources, such as, but not limited to, deliveryagents, subscribers, payees, and/or any other third party source.

Moreover, some of the additional delivery method factors 620 capturedmay be further analyzed by the delivery method module. For example, inone embodiment in which the delivery method factors 620 include deliverycosts, the cost data associated with the delivery history informationcan be analyzed in a manner similar to that described with reference toFIG. 3, such as to determine whether there is sufficient volume of costdata collected over a given period of time, to avoid excessive variancein the cost data captured, to remove outliers, and/or to normalize orotherwise account for seasonal cost variations for comfortably arrivingat or otherwise using an average or expected cost associated with eachdelivery method. For other, non-numerical delivery method factors 620,other analysis techniques can be used to most accurately predict whatthat factor indicates about the associated delivery method (e.g.,indicate availability to subscribers and/or payees, priority services,etc.).

Following block 730 is decision block 735, in which it is determined ifthere are any limitations to utilizing the previously identifieddelivery methods for the payee. If there are, then block 740 follows,and the delivery methods not available to the subscriber are optionallyexcluded from subsequent analysis, according to one embodiment.

According to various embodiments, subscribers may be limited to a subsetof the otherwise available delivery methods. Various limitations mayinclude, but are not limited to, subscriber account privileges, servicelevel limitations for the customer, and the like. As one example, aservice provider may only provide delivery services from a certaindelivery agent or priority services to customers paying for, orotherwise receiving, a certain level of service from the serviceprovider, such as may occur with larger institutions or upgradedaccounts, for example. Thus, at block 735, the service provider and itsdelivery method module 113 can be configured to retrieve subscriberinformation, such as, but not limited to, account information and/orservice level information, to identify which delivery methods are notavailable to the subscriber. The delivery method module 113 isconfigured to exclude unavailable delivery methods from subsequentanalysis when selecting the preferred delivery method.

If there are no limitations to the identified delivery methods, or aftervarious delivery methods are excluded, then block 745 follows. It isalso appreciated that, according to other embodiments, the processing atblock 745 may not be performed, such as when the method 700 is performedindependent of a user interface request.

At block 745 estimated lead time data 610 and/or additional deliverymethod factors 620 are analyzed to facilitate selecting a deliverymethod. According to various embodiments, the delivery method module 113can be configured to input the estimated lead time data 610 and/or anyadditional delivery method factors 620 to an algorithm to facilitateselecting a delivery method.

As one example, prior to applying the inputs to an algorithm, each ofthe estimated lead time data 610 and additional delivery method factors620 may be converted to a numerical score (e.g., ranging from 1 to 5, 1to 10, 1 to 100, etc.). The algorithm may be created to weight each ofthe scores, permitting the service provider to prioritize the factorsbeing considered. For example, the service provider may selectivelyemphasize and de-emphasize one or more of the estimated lead times andadditional factors as compared to the other inputs. Thus, uponprocessing the data associated with each of the available deliverymethods, the lowest score (or highest, depending upon the algorithmapplied) may indicate the preferred delivery method, at least asdetermined based on the chosen algorithm. Other means of prioritizationmay also be utilized.

According to one embodiment, various algorithms may be created andselected for different situations, such as for different subscribers,for different subscriber types, for different payees, for different daysof the week, for different economic conditions, and the like. Accordingto another embodiment, the delivery method module 113 may be configuredto present delivery options to an operator, such as a prioritized listbased on the results of the algorithm, etc., so that the operator canmanually select the preferred delivery method.

According to other embodiments, various other techniques may beperformed to analyze the estimated lead time data 610 and any additionaldelivery method factors 620 associated with each of the availabledelivery methods. For example, other techniques include, but are notlimited to, analyzing only estimated lead time, analyzing only one ormore of the additional factors (e.g., only based on cost, only based ondistribution center, etc.), and the like.

Following block 745 is block 750, in which a preferred delivery method(if there were multiple available delivery methods) is associated withthe payee, such as by storing in a payee table of the database 119, amanaged payee data repository, a personal payee list, or forpresentation via a user interface. It is appreciated that various othertechniques can be performed for storing and/or associating the preferreddelivery method 630 with one or more payees, one or more geographicalareas, one or more delivery routes, one or more subscribers, etc.,according to other embodiments.

While the method 700 is described as selecting one of multiple availabledelivery methods in response to identifying a payee (e.g., receiving apayment request from a subscriber), according to other embodiments, thepreferred delivery method 630 can be selected from available deliverymethods independent of receiving a payment request transaction toidentify a payee. For example, according to one embodiment, some or allof the steps illustrated in this method 700 can be performed to generateor update payee information to indicate the preferred delivery method630, which can be stored for subsequent processing and analysis. In oneexample, multiple payees can be identified, and some or all of the stepsof the method 700 are repeated for each payee identified. According toanother embodiment, some of the steps of the method 700 can be performedto generate or update a delivery method table to indicate a preferreddelivery method 630 for delivering mailpieces to each of multiplegeographical areas (e.g., preferred delivery method 630 per zip code).For example, instead of identifying a payee, the method 700 can beginwith a similar step as performed at block 710, in which one or moregeographical areas are identified and some or all of the subsequentsteps are repeated for each geographical area. Accordingly, analyzingand selecting a preferred delivery method 630 prior to processingpayments and/or preparing mailpieces for delivery enables a serviceprovider to make more informed decisions on delivery methods duringsubsequent processing.

Moreover, according to various embodiments, the method of selecting apreferred delivery method, as described with reference to FIGS. 6 and 7,can be performed in association with the method of determining estimatedlead times. For example, according to one embodiment, before presentingan estimated lead time to a subscriber, if it is determined thatmultiple delivery methods are available, a preferred delivery method canbe selected according to embodiments described with reference to FIG. 7,and the corresponding estimated lead time can be presented to thesubscriber according to the embodiments described with reference toFIGS. 4A-4B.

The method 700 can end after block 750, having selected a preferreddelivery method from multiple available delivery methods based at leastin part on lead time estimations and/or other delivery methodcharacteristics performed by analyzing mailpieces previously deliveredto same or similar geographical areas.

Accordingly, as described herein with reference to FIGS. 1-7,embodiments of the invention provide for selecting a preferred deliverymethod from multiple available delivery methods for delivery to a givengeographical area, and for estimating payment lead time associated withthe delivery method selected. The selection of a delivery method and theestimation of lead times are accomplished by analyzing delivery historyinformation that includes mailpieces delivered to the same or similargeographical areas and via the same delivery methods. By groupingdelivery history information by geographical areas, and optionally bydelivery methods, a service provider can analyze greater volumes of dataassociated with actual deliveries, and thus more accurately predictestimated lead times. In addition, by collecting and analyzingadditional delivery method factors, such as delivery costs, inassociation with the delivery history information collected andanalyzed, the service provider can make more informed and intelligentdecisions about which delivery method to a given geographical area suitsthe service provider's requirements and accomplishes its business andeconomic needs.

While the above description describes embodiments of the inventiondirected toward printing and mailing paper instruments to payees via apayment service provider, other embodiments of the invention are notlimited to payment processing. The systems and methods described hereincan be adapted to provide estimated lead times and to select deliverymethods in association with the delivery of any mailpiece, not justthose associated with payments. For example, where example systems andmethods are described as being associated with and/or performed by aservice provider performing payment processing functions, any otherservice provider or other entity may provide embodiments of the systemsand perform embodiments of the methods described herein. Also, wheretransaction processing in association with an electronic billpresentment and payment processing application are generally described,any other application operable to display payment lead times and/or toreceive delivery parameters may be provided. In addition, where examplemethods are described as identifying payees, any mailpiece recipient canbe identified and similar lead time and/or delivery method selectionperformed. Accordingly, it is to be appreciated that the exampleembodiments described herein are not intended to limit variousembodiments of the invention to payment processing and delivery ofpayment-related mailpieces.

The invention is described above with reference to block and flowdiagrams of systems, methods, apparatuses, and/or computer programproducts according to example embodiments of the invention. It will beunderstood that one or more blocks of the block diagrams and flowdiagrams, and combinations of blocks in the block diagrams and flowdiagrams, respectively, can be implemented by computer-executableprogram instructions. Likewise, some blocks of the block diagrams andflow diagrams may not necessarily need to be performed in the orderpresented, or may not necessarily need to be performed at all, accordingto some embodiments of the invention.

In certain embodiments, performing the specified functions, elements, orsteps can transform an article into another state or thing. Forinstance, example embodiments of the invention can provide certainsystems and methods that transform mailpiece delivery historyinformation representative of actual past mailpiece deliveries from oneor more distribution centers to one or more recipients into estimatedlead times representative of actual mailpiece deliveries andcorresponding documentation, such as print orders, delivery requests,and the like. In another example, embodiments of the invention canprovide certain systems and methods that transform mailpiece deliveryhistory information representative of actual past mailpiece deliverymethods into a preferred delivery method representative of subsequentdeliveries and corresponding documentation, such as print orders,delivery requests, and the like.

These computer-executable program instructions may be loaded onto ageneral-purpose computer, a special-purpose computer, a processor, orother programmable data processing apparatus to produce a particularmachine, such that the instructions that execute on the computer,processor, or other programmable data processing apparatus create meansfor implementing one or more functions specified in the flow diagramblock or blocks. These computer program instructions may also be storedin a computer-readable memory that can direct a computer or otherprogrammable data processing apparatus to function in a particularmanner, such that the instructions stored in the computer-readablememory produce an article of manufacture including instruction meansthat implement one or more functions specified in the flow diagram blockor blocks. As an example, embodiments of the invention may provide for acomputer program product, comprising a computer usable medium having acomputer-readable program code or program instructions embodied therein,said computer-readable program code adapted to be executed to implementone or more functions specified in the flow diagram block or blocks. Thecomputer program instructions may also be loaded onto a computer orother programmable data processing apparatus to cause a series ofoperational elements or steps to be performed on the computer or otherprogrammable apparatus to produce a computer-implemented process suchthat the instructions that execute on the computer or other programmableapparatus provide elements or steps for implementing the functionsspecified in the flow diagram block or blocks.

Accordingly, blocks of the block diagrams and flow diagrams supportcombinations of means for performing the specified functions,combinations of elements or steps for performing the specifiedfunctions, and program instruction means for performing the specifiedfunctions. It will also be understood that each block of the blockdiagrams and flow diagrams, and combinations of blocks in the blockdiagrams and flow diagrams, can be implemented by special-purpose,hardware-based computer systems that perform the specified functions,elements or steps, or combinations of special-purpose hardware andcomputer instructions.

Many modifications and other embodiments of the invention will come tomind to one skilled in the art to which this invention pertains andhaving the benefit of the teachings presented in the foregoingdescriptions and the associated drawings. Therefore, it is to beunderstood that the invention is not to be limited to the specificembodiments disclosed and that modifications and other embodiments areintended to be included within the scope of the appended claims.Although specific terms are employed herein, they are used in a genericand descriptive sense only and not for purposes of limitation.

1. A system, comprising: one or more computers comprising: at least onememory storing computer-executable instructions; and at least oneprocessor configured to access the at least one memory and to executethe computer-executable instructions to: identify first informationassociated with a set of first events associated with a first set ofmailpieces mailed to a geographical area, wherein each mailpiece of thefirst set of mailpieces comprises a respective payment instrumentassociated with a respective payment; identify second informationassociated with a set of second events associated with the first set ofmailpieces, wherein each second event of the set of second events isassociated with one of: i) the respective payment instrument or ii) therespective payment, of a corresponding mailpiece of the first set ofmailpieces; determine, based at least in part on the first informationand the second information, a set of delivery times associated with thefirst set of mailpieces; determine, based at least in part on ananalysis of the set of delivery times, an estimated lead time associatedwith subsequent delivery of a second set of one or more mailpieces tothe geographical area; identify a payee; determine that the payee isassociated with the geographical area; and associate the estimated leadtime with the payee.
 2. The system of claim 1, wherein: the firstinformation comprises a set of first dates associated with the set offirst events, wherein each date of the set of first dates is associatedwith a respective mailpiece of the first set of mailpieces, the secondinformation comprises a set of second dates associated with the set ofsecond events, wherein each date of the set of second dates isassociated with a respective mailpiece of the first set of mailpieces,and to determine the set of delivery times, the at least one processoris configured to execute the computer-executable instructions todetermine a respective delivery time associated with each mailpiece ofthe first set of mailpieces, wherein each respective delivery timecomprises an elapsed time between a respective first date of the set offirst dates and a respective second date of the set of second dates. 3.The system of claim 2, wherein each date of the set of first datescomprises one of: i) a respective mailing date associated with mailingof the respective mailpiece, or ii) a respective printing dateassociated with printing of the respective payment instrument of therespective mailpiece.
 4. The system of claim 2, wherein the secondinformation comprises at least one of: i) delivery status information,ii) check clearance information, iii) payment posting information, oriv) payment receipt information.
 5. The system of claim 4, wherein eachdate of the set of second dates comprises one of: i) a respectivedelivery date indicative of a date on which a delivery agent deliveredthe respective mailpiece, wherein the delivery status informationcomprises the respective delivery date, ii) a respective clearing dateindicative of a date on which the respective payment instrument of therespective mailpiece was cleared, wherein the check clearanceinformation comprises the respective clearing date, iii) a respectiveposting date indicative of a date on which a payee posted the respectivepayment associated with the respective payment instrument, wherein thepayment posting information comprises the respective posting date, oriv) a respective receipt date indicative of a date on which the payeereceived the respective payment, wherein the payment receipt informationcomprises the respective receipt date.
 6. The system of claim 1,wherein, to identify the second information, the at least one processoris configured to execute the computer-executable instructions to:receive the second information from one or more external entities. 7.The system of claim 6, wherein the one or more external entitiescomprise at least one of: i) a delivery agent, ii) a financialinstitution, or iii) a payee.
 8. The system of claim 1, wherein, todetermine the estimated lead time, the at least one processor isconfigured to execute the computer-executable instructions to: perform astatistical analysis on the set of delivery times.
 9. The system ofclaim 1, wherein, to identify the payee, the at least one processor isconfigured to execute the computer-executable instructions to: receive,on behalf of a payor, a request to make a payment to the payee; andidentify the payee based at least in part on the received paymentrequest.
 10. The system of claim 9, wherein the at least one processoris further configured to execute the computer-executable instructionsto: determine a payment mail date for mailing the payment to the payeebased at least in part on the estimated lead time associated with thepayee.
 11. The system of claim 1, wherein the first set of mailpieces isassociated with a first set of one or more delivery factors, wherein theset of delivery times is a first set of delivery times, wherein theestimated lead time is a first estimated lead time associated with thefirst set of one or more delivery factors, and wherein the at least oneprocessor is further configured to execute the computer-executableinstructions to: determine a second set of delivery times associatedwith a third set of mailpieces mailed to the geographical area, whereinthe third set of mailpieces is associated with a second set of one ormore delivery factors; and determine, based at least in part on ananalysis of the second set of delivery times, a second estimated leadtime associated with the subsequent delivery of the second set of one ormore mailpieces mailed to the geographical area, wherein the secondestimated lead time is associated with the second set of one or moredelivery factors.
 12. The system of claim 11, wherein each deliveryfactor of the first set of one or more delivery factors and eachdelivery factor of the second set of one or more delivery factors isassociated with a respective type of delivery factor, wherein therespective type of delivery factor comprises one of: (i) a distributioncenter, (ii) a delivery agent, (iii) a delivery path, (iv) a deliverycost, or (v) a delivery priority.
 13. The system of claim 12, wherein afirst delivery factor of the first set of one or more delivery factorsand a second delivery factor of the second set of one or more deliveryfactors correspond to a same type of delivery factor, wherein the firstdelivery factor is different from the second delivery factor, andwherein, to associate the estimated lead time with the payee, the atleast one processor is configured to execute the computer-executableinstructions to: select one of the first estimated lead time or thesecond estimated lead time; select one of: i) the first delivery factoror ii) the second delivery factor, wherein the selected delivery factoris associated with the selected estimated lead time; and associate theselected delivery factor with the payee.
 14. The system of claim 1,wherein the at least one processor is further configured to execute thecomputer-executable instructions to: determine a latest available dateto request a payment to the payee based at least in part on theestimated lead time and a payment due date associated with the payment;and communicate an indication of the latest available date forpresentation to a subscriber.
 15. A method, comprising: identifying, bya service provider system comprising one or more computers, firstinformation associated with a set of first events associated with afirst set of mailpieces mailed to a geographical area, wherein eachmailpiece of the first set of mailpieces comprises a respective paymentinstrument associated with a respective payment; identifying, by theservice provider system, second information associated with a set ofsecond events associated with the first set of mailpieces, wherein eachsecond event of the set of second events is associated with one of: i)the respective payment instrument or ii) the respective payment, of acorresponding mailpiece of the first set of mailpieces; determining, bythe service provider system and based at least in part on the firstinformation and the second information, a set of delivery timesassociated with the first set of mailpieces; determining, by the serviceprovider system and based at least in part on an analysis of the set ofdelivery times, an estimated lead time associated with subsequentdelivery of a second set of one or more mailpieces to the geographicalarea; identifying, by the service provider system, a payee; determining,by the service provider system, that the payee is associated with thegeographical area; and associating, by the service provider system, theestimated lead time with the payee.
 16. The method of claim 14, wherein:the first information comprises a set of first dates associated with theset of first events, wherein each date of the set of first dates isassociated with a respective mailpiece of the first set of mailpieces,the second information comprises a set of second dates associated withthe set of second events, wherein each date of the set of second datesis associated with a respective mailpiece of the first set ofmailpieces, and determining the set of delivery times comprisesdetermining a respective delivery time associated with each mailpiece ofthe first set of mailpieces, wherein each respective delivery timecomprises an elapsed time between a respective first date of the set offirst dates and a respective second date of the set of second dates. 17.The method of claim 16, wherein each date of the set of first datescomprises one of: i) a respective mailing date associated with mailingof the respective mailpiece, or ii) a respective printing dateassociated with printing of the respective payment instrument of therespective mailpiece.
 18. The method of claim 16, wherein the secondinformation comprises at least one of: i) delivery status information,ii) check clearance information, iii) payment posting information, oriv) payment receipt information.
 19. The method of claim 18, whereineach date of the set of second dates comprises one of: i) a respectivedelivery date indicative of a date on which a delivery agent deliveredthe respective mailpiece, wherein the delivery status informationcomprises the respective delivery date, ii) a respective clearing dateindicative of a date on which the respective payment instrument of therespective mailpiece was cleared, wherein the check clearanceinformation comprises the respective clearing date, iii) a respectiveposting date indicative of a date on which a payee posted the respectivepayment associated with the respective payment instrument, wherein thepayment posting information comprises the respective posting date, oriv) a respective receipt date indicative of a date on which the payeereceived the respective payment, wherein the payment receipt informationcomprises the respective receipt date.
 20. The method of claim 1,wherein identifying the second information comprises receiving, by theservice provider system, the second information from one or moreexternal entities, and wherein the one or more external entitiescomprise at least one of: i) a delivery agent, ii) a financialinstitution, or iii) a payee.
 21. The method of claim 1, wherein thefirst set of mailpieces is associated with a first set of one or moredelivery factors, wherein the set of delivery times is a first set ofdelivery times, and wherein the estimated lead time is a first estimatedlead time associated with the first set of one or more delivery factors,further comprising: determining, by the service provider system, asecond set of delivery times associated with a third set of mailpiecesmailed to the geographical area, wherein the third set of mailpieces isassociated with a second set of one or more delivery factors; anddetermining, by the service provider system, based at least in part onan analysis of the second set of delivery times, a second estimated leadtime associated with the subsequent delivery of the second set of one ormore mailpieces mailed to the geographical area, wherein the secondestimated lead time is associated with the second set of one or moredelivery factors.
 22. The method of claim 21, wherein each deliveryfactor of the first set of one or more delivery factors and eachdelivery factor of the second set of one or more delivery factors isassociated with a respective type of delivery factor, wherein therespective type of delivery factor comprises one of: (i) a distributioncenter, (ii) a delivery agent, (iii) a delivery path, (iv) a deliverycost, or (v) a delivery priority.
 23. The method of claim 22, wherein afirst delivery factor of first set of one or more delivery factors and asecond delivery factor of the second set of one or more delivery factorscorrespond to a same type of delivery factor, wherein the first deliveryfactor is different from the second delivery factor, and whereinassociating the estimated lead time with the payee further comprises:selecting, by the service provider system, one of the first estimatedlead time or the second estimated lead time; selecting, by the serviceprovider system, one of: i) the first delivery factor or ii) the seconddelivery factor, wherein the selected delivery factor is associated withthe selected estimated lead time; and associating, by the serviceprovider system, the selected delivery factor with the payee.
 24. One ormore computer-readable media storing computer-executable instructionsthat in response to execution cause operations to be performedcomprising: identifying first information associated with a set of firstevents associated with a first set of mailpieces mailed to ageographical area, wherein each mailpiece of the first set of mailpiecescomprises a respective payment instrument associated with a respectivepayment; identifying second information associated with a set of secondevents associated with the first set of mailpieces, wherein each secondevent of the set of second events is associated with one of: i) therespective payment instrument or ii) the respective payment, of acorresponding mailpiece of the first set of mailpieces; determining,based at least in part on the first information and the secondinformation, a set of delivery times associated with the first set ofmailpieces; determining, based at least in part on an analysis of theset of delivery times, an estimated lead time associated with subsequentdelivery of a second set of one or more mailpieces to the geographicalarea; identifying a payee; determining that the payee is associated withthe geographical area; and associating the estimated lead time with thepayee.